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PROTOCOL STACKS 



TMs invention relate, to protocol stacks and to communications systems such as 



.elecornmunications systems incorpon.^ F — ol stacks, 
reconfigurable radios (SWRs) or soft-radios. 

top of each other i.e. a stratification approach, each layer offering * internal 
tonality to other layers and the application via standardized interfaces known as 
Service Access Points (SAPs). 

each of which has certain functionality and serves a certain task. Traditionally, 
protocol frameworks use the stratification approach as a composition mechanism. 
Protocolstnonelayerofmes^ckare-mpervioustotheproperfiesofmelayershelow. 
Eachlayer^eatedasa'hlackbox^dmereexistsnomechanismtoidenfify/hypass 
any functional redundancies, which may occur in the stack. A weil-documented 
example ofprotocol stacks is the OSmM(Open Systems Interconnection Reference 
Mode,) which consists of seven layers rangmg from application, presentation, 
s ession, transport, network and data link layers to the physical layer. Each of these 
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layers represents a complete protocol that offers its services to the next upper layer or 
expects services from the layer immediately below. This structure is described in 
"Computer Networks" by A.S. Tanenbaum, 3rd Ed, Prentice-Hall, 1996. The same 
principle applies to both mobile and fixed line telecommunication networks, and 
hence interworking functionality is defined in separate protocols. Communication 
between layers is accomplished via SAPs. Through these SAPs sets of primitives in 
a given layer become available to the next layer up the hierarchy. Services define 
operations to be performed within the layer and can be requested by upper layers. In 
effect, SAPs are used" to encapsulate the layers, to hide their complexity and to 
uniquely describe the functionality that a layer provides and what upper layer users 
may request from them. However, SAPs are static and lack any flexibility. They do 
not support flexible changes in the protocol stack and need to be re-standardised in 
case any change becomes necessary. 



These shortcomings of conventional protocol stacks present, inter alia, a significant 
obstacle to the implementation of SWRs which are evolving towards all-purpose 
radios which can implement a variety of different standards or protocols through re- 
programming (see, for example, "The Software Radio Architecture" by J Mitola m, 
IEEE Comm. Mag. May 1995 pp 26-38 and "The Layered Radio" by M Butler et al, 
MILCOM, NY, 1998 pp 179-179). SWRs are emerging as viable alternatives to 
multimode terminals without the "Velcro approach" of including each 
possible/existing standard. Therefore, next generation mobile terminals and network 
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nodes will require significantly richer capabilities in the control plane due to the need 
to support large numbers of diverse applications with different Quality of Service 
(QoS) requirements and traffic characteristics. 

SWR terminals will also need to be reprogrammable and this reconfiguration 
requirement will not be confined to the physical layer alone. In summary, future SWR 
terminals and devices as well as network entities will only be able to efficiently 
respond to the needs of applications and user preferences if the capability to software 
download, reconfiguration and management are provided within terminals and 
supported by the network infrastructure. However, this cannot be achieved with the 
existing rigid protocol stratification approach. 

One objective of the present invention is to alleviate at least some of the 
aforementioned problems by providing a protocol stack having active programming 
interfaces (Protocol Programming Interfaces (PPIs)/Application Programming 
Interfaces (APIs)) replacing the rather static SAPs used in conventional protocol 

stacks. > 

As described in "Towards an Active Network Architecture" by D Tennenhouse et al, 
Comp. Commun. Rev Vol 26, No. 2, Apr 1996, in "Active Networking Sources for 
Wired/Wireless Networks" by A Kulkami et al, Proc. INFOCOM 99, Vol 3, NY 1999, 
pp 1 1 16-23 and in "Composing Protocol Frameworks for Active Wireless Networks" 
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by A Kulkarni et al IEEE Commun Mag Mar 2000 deployment of active nodes and 
interfaces would certainly facilitate introduction of differentiated or integrated 
services to support new multimedia applications as well as provide for smoother 
interworking functionality between media protocols (internet and IN) or different 
signalling systems (SS7, H323 etc). Also network management would become more 
intelligent and network capabilities would evolve rapidly through software changes 
without the need to upgrade the network infrastructure. Thus, it is envisaged that 
future reconfigurable mobile networks would benefit greatly from the deployment of 
active nodes and service interfaces. 

Re-configuration through introduction of prograniming interfaces between protocol 
strata opens up the possibility to write both single protocols or even whole protocol 
stacks in a manner similar to the way applications are written in high level 
programming languages (e.g. Java applications use different APIs which are part of 
the class libraries with binding at runtime - this means that the functionality is out- 
sourced to the API and the application simply defines the sequence and determines the 
parameters passed to methods within the APIs). Other important design issues in 
software radio design concern proper reconfiguration of the radio i.e. reconfiguration 
management, which is responsible for runtime reconfiguration management, over-the- 
air down load protocol .(described in "Terminal Reconfigurability - The Software 
Download Aspect" K Moessner et al IEE Int Conf On 3G 2000, Mar 2000, London 
UK) and security related aspects. 
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Alternative well-documented approaches to this general problem include the "Mobile 
Application Support Environment" (MASE) developed as part of the ACTS project 
"On The Move", the Global Mobile API Framework, the Mobile Station Application 
Execution Environment (MExE) GSM 02.57 V70.0 ETSI, 1998 and IEEE PI 520, the 
proposed IEEE Standard for Application Progi^miming Interfaces for Networks. 

According to the invention there is provided a protocol stack for a communications 
system wherein the stack has an architecture incorporating active programming 
interfaces capable of supporting reconfiguration of the stack. 

Active programming interfaces are objects and need to comply to the object-oriented 
design principles i. 

The invention introduces a novel concept that Tedefines the interfaces between 
protocol layers, classifies interactions between different layers within the; protocol 
stack and provides an architecture supporting protocol reconfiguration. This can be 
achieved by implementing active programming interfaces as objects within the 
protocol stack and by using object oriented design methods to define this new protocol 
stack architecture. Standardised active progxanumng interfaces will introduce the 
additional degree of freedom necessary for standard reconfiguration of protocol stacks 
in both terminal and network. 
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Embodiments of the invention are now described, by way of example only, with 
reference to the accompanying drawings of which: 

Figure 1 illustrates the comparison between the control (C) planes of the legacy GSM 
and the 'active programming interface' protocol stacks, 

Figure 2 illustrates thread controlled message handling, 

Figure 3 illustrates a protocol stack structure and protocol stack class libraries, 

Figure 4 illustrates pro-layer classes, 

Figure 5 illustrates interface class hierarchy, 

Figure 6 illustrates the thread class hierarchy, 

Figure 7 illustrates interface primitives, 

Figure 8 illustrates PS class relations, 

Figure 9 illustrates hierarchy and class relations, 



and 
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Figure 10 illustrates active interface objects, 



Figure 11 illustrates class relations witinn the protocol stack, 



Figure 12(a) illustrates sample skeleton code, 

. fr.m«works for pro-layers and pro-interfaces 
Figure 12(b) illustrates class frameworKs ror p 

provides an example of a thread class, 

Figure 13 illustrates a model implementation protocol stack, 

FigureMiUustratesaserverappletusedinthemodelofFigurelS, 

Figure 15 illustrates a client applet used in the model ofFigure 13 and 
Figure 16 illustrates QoS modification message sequence, 
rneembodimentstobedes^^ 

mo del and architecture referred to hereinafter as OWMA. 
H. THE OPtlMA APPROACH 
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Software reconfiguration has been identified as a crucial technology to facilitate the 
realisation of software-defined radios. The main functionality of interest is the ability 
to exchange protocol software l on the fly' and to reconfigure complete protocol stacks, 
which may become necessary in various circumstances. 

The approach presented here implements a framework for protocol stack 
reconfiguration. Protocol stacks are split into a number of functional entities 
described in terms of generic "classes" organised in class libraries, with dynamic 
binding at runtime to implement reconfigurable protocol stacks. The framework is 
also capable of supporting composible protocols. A single protocol layer may be 
replaced by a collection of components each of which implements a particular 
function. Inside a soft-radio terrninal for instance, a "Reconfiguration Management" 
unit would control component selection, deletion/upgrade and communication with 
the PPIs. With the OPtlMA specification, there is also provided guidelines to build/ 
implement standardised and proprietary protocol stacks using the defined APIs and 
PPIs. 

II. 1 APPLICATION PROGRAMMING INTERFACES AND OBJECT 
ORIENTATED DESIGN. PRINCIPLES 



Interfaces, in general, are representations of point of access to hidden functionality in 
some underlying layer. The purpose of such interfaces is to encapsulate the 
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complexity of any fimctiona^plemeotati on and to offer to shnples. possible form 
of access to this functionality to the user/progranrnrer/application. 

AppHcation Programming Interface (APIs), in generai, rely on to paradigm to, 
^.cesMdatoc^lexityofhowamedonaU^isac^Uyre^.Wsen*^ 

programmers to simply apply to guidelines of howan interface has tobensed and 
whichparameters are to be passed for each single fimction call. Applications become 
sequences of calls to functions pre-defined within these API implementations. Much 
of to complexity within such applications is therefore moved down, below these 
programming interfaces. One of to advantages of APIs is ton extensibility and 
partial or even complete exchangeability without necessarily requiring to complete 

re-witing of to application code. Otor benefits of pmgmmming interfaces include 

the scalability and to simple use of such structures. 

Ttebasicideaof Object Orientation is to put a system's behaviour and its properties 
^discmteentitiesasd^ed.forexample.in-Ohjec.OrientedAnalysis.byCoad 

et a,,2nd E dition,EnglewoodC.i^N I: Vourden Press, .991andthis requires to, 
fhnotionaUy different of a system have, „ be identified. Once inter-relahcnships 
between entities andstate or behaviour. (*mctional W of tose entities are analysed, 
aformalisationand description as classes has ,0 be done. Objec, Orientation relies on 
a number of basic principles of which to class is to major one; mrther concepts 
include Objects, Absteaction, Attributes, Operations/Methods/Services, Messages, 
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Encapsulation, Inheritance, Polymorphism and Reuse as described in "Object 
Oriented Analysis and Design with Applications, by G Booch, 2nd Edition, 
Benjamin/Cummings Publishing, Redwood City, CA, 1 99 1 . Examples in which OOD 
and APIs are used together are manifold. For example, most parts of the JFC (Java 
Foundation Classes) are implemented in classes, which are derived (via one to several 
levels of hierarchy) from the base class 'object'. The same applies for the MFC 
(Microsoft Foundation Classes), which contain the base implementation classes for 
application programming for the Windows platform. 

II.2 SYSTEM ARCHITECTURE 

One objective of the OPtlMA model is to introduce a framework, which enables the 
exchange of protocols during run-time as well as the active involvement of the 
interfaces that enable direct signalling communication between interfaces of different 
protocol stack layers without accessing the layer implementation. This requires a 
somewhat different system view; in this approach protocols become split into 'pro- 
interfaces' and 'pro-layers', as shown in Figure 1 . 

Pro-interfaces are active implementations defined within classes, which are derived 
from a base class. Here entity definitions are according to their position in the stack 
(pro-interface -+ between two pro-layers). This base class defines the generic 
functionality of all possible pro-interfaces. Further specialisation can then be 
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achieved within the derived pro-interface classes. When impie.nen.en as objects, 
interfaces (i... pro-interfaces) deliver both additional functionality and additional 
architectural complexity. 

jB^a* the actual protocol Cementations. which obtain data thronghpro- 
iuterfaces, manipulate titese data and export then, throngb the pro-interfaees. 
Execution of fenctions/meflmds within pro-interface and pro-layer Casses is 
connoUedbytinnad-objec^.Snchaconsnnctionde.iversahigb.y flexible platform 

t0 replace the classical protocol stacks and to enable flexible stack reconfiguration 
during nm-time. In other words, thread objeets are implementing classes, which 
control message transport and manipulation faoughou, a„ pro-layers and pro- 
interfaces. 

Upon arrival.attaead.akes over responsibility for taemessages and their processing 
wiai mti 1 ecomple.epro.ocols.aek.hd«he»passes te rcferencesofmeseme S sage S 

,o their destinations, aa illustrated in Figure 2. 
n.3 CLASS ARCHITECTURE 

Afunctional decomposition' of protocol stacks representing the composition ofthe 
basic entities for a open protocol implementation is illustrate* in Figures. 
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Four different class types have been identified which are: 
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1. Layer classes (L-classes defining pro-layers) represent the functionality of 
single protocols within the protocol stack (i.e. physical(P-L)- s linkfLCL)-, network 
(NCL)- and signalling application(BSA)-functionality). Layer classes (pro-layers) 
inherit functionality from a generic (pro-) layer class (GLC), as shown in Figure 4. 

2. Programming Inter face classes (Pi-classes defining pro-interfaces) represent 
the various programming interfaces between the protocols (L-classes). Pi-classes 
consist of methods that further specify and implement the generic primitives defined 
in a base class (GPI). The class structure and the primitive description are shown in 
Figures 5 and 7 respectively. Pi-classes detect events (i.e. messages from some 
protocol) and trigger the execution of the appropriate thread. 

3 . Thread classes (T-classes) implement pre-defined procedures (e.g. Connection- 
, Mobility-, Radio Resource- or QoS-Management - signalling). Other, non-defined 
and non-standardised, signalling procedures may be implemented within customised 
thread classes e.g. (SST), as illustrated in Figure 6. In addition to the implementation 
of message sequences, threads also enhance the flexibility of the complete protocol 
stack. The use of threads to execute signalling procedures enables programmers to 
implement several signalling procedures in parallel. This feature may be 
advantageous in regard to point to multipoint communications. Thread classes 



PCT/GBU1/U216'J 

WO 01/811707 

13 

and use the methods defined in PI- and L-classes. 



4 fcaosauaa*^ (PS-class) defines and represents tie implementation of 
.oompleteprotoeo^o.c.Dirr^tiegacysmcksCe^.meGSMstac^maynsemen 

Rifled constructors to include the appropriate classes to implement the standard 
w hi.st other stacks may he fieely defined. The PS-class is the only Cass puhlic.y 
accession within the protocol class library, Instances of mis Cass implement any 
chosenprotocolstackfi.nctionalihy.FufihennorcUaePS-Cass manages protoco, re- 

configmahi.irywhenL-^-orT-C.sses are exchanged during nm-time, as illustrated 
inFigumS.As.hown.nretmeadCassestSS^usememodsdefinedinbo.h.heP! 

and L classes. 

In summary, L, PI and T classes define the capabilities, methods and properties of a 
protocol stack, whereas the PS-class implements those classes and so defines also the 
protocol stack structure. 

II.4 DESIGN GUIDELINES , 

OPfiMAreliesonmeaforemenfionedclassesandasetofdesignrules, which define 
how classes and the complete protocol stack ought ,o be implemented. Basis forme 
protocol stack implementation is a Code-skeleton, shown in Figures 12a and 12b, m 



which the 



different interface and layer classes become implemented. 



WO 01/88707 PCT/GB01/02169 
14 

The 'Protocol Stack* class, within one protocol stack, is the only class exporting public 
interfaces; it implements L-, PI- and T-objects and defines the structure of the protocol 
stack. The architecture as a whole uses inheritance to define a hierarchy of both 
different interface and different layer classes; therefore, it uses a generic interface 
class and a basic protocol class to derive pro-interfaces and pro-layers, respectively. 

n.5 PROTOCOL STACK AND THREAD CLASSES 



The three groups of classes (Pi,L,T) are instantiated, implemented and controlled by 
an instance of the Protocol Stack Class ; this PS-object defines therefore the complete 
protocol stack. Classes within one of the functional groups (threads, interfaces and 
layers) are located within class libraries, each of which provides the functionality for 
their particular group of specialised (derived) classes. Figure 3 shows the 
dependencies and the 'logical location' of classes within the protocol stack and their 
class libraries. Thread classes are those entities that actually manage the message 
passing throughout the protocol stack; they are used to handle single message 
sequences (i.e. each thread controls one sequence). 

HI. COMPOSITION OF PROTOCOL LAYERS AND INTERFACES 

Separation of the protocol stack functionality into pro-layers and pro-interfaces forms 
a new paradigm for protocol stack development where dissemination of functionality 
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is facilitated through open protocol prograrnrning interfaces. In the illustrated 
implementation, the OPtlMA architecture consists of five layers each having its own 
tasks and functionality. All entities within the •decomposed' protocol stack (including 
pro-layers, p ro -mterfaces and Threads) are implemented as sep^ 
classes (L-classes) contain the attributes of their protocols (layers) and are used to 
store information obtained from (and related to) corresponding pro-layers. L-class 
methods are used to process incoming information and to produce an adequate 
response or initiate follow up sequences. In this particular embodiment, the Layer 
classes and their main functions are: 

o Physical Layer, (modem, channel access, FEC, ciphering, etc.) -, 

□ Link Layer Control, (link control) 

□ Network Control Layer, (controls message routing) 

□ Signalling Application Layer, (Connection Management, Resource and 
Mobility Management signalling) 

□ Application Layer, applications need to be compliant to the API specification 

m.l ACTIVE PROGRAMMING INTERFACES 

Pro-layers are separated and isolated by pro-Interfaces (PI), which ensure 
exchangeability and extensibility of protocol implementations during runtime. 
Protocol in this context refers to alegacy protocol, in contrasts the pro-layer which 
is the implementation of legacy (and possible proprietary) protocol functionality 
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within OPtlMA. Appropriate Pis are defined (see class architecture (Figure 5» and 
introduced between the protocol implementations (pro-layers). Pro-interfaces provide 
the open protocol-programming platform; they enable interchange of signalling 
messages and deliver access to pro-layer classes. In this embodiment, four pro- 
interface classes are defined to implement a complete protocol stack (as shown in 
Figure 5): 

a PPI12 (between Physical Layer and Link Layer Control) 

n PPI23 (between Link Layer Control and Network Control Layer) 

□ PPI34 — '- (between Network Control Layer and Signalling Application 

Layer) 

Q API (Application Programming Interface) 

Pro-interfaces are derived from a generic interface class (GPI) which defines four 
basic types of control messages known as primitives, whose task is to inform 
respective pro-layers about events, pass new values for variables between the pro- 
layers and trigger methods implemented in these pro-layer classes. Referring to 
Figure 7, these four 'primitive' types are: 

□ Service Request Messages (SRM): Asynchronous primitive to perform 
immediate, typically non-persistent actions. The flow direction for a SRM is 
from a high layer to a lower one. 



□ Request Responses (RR): Persistent state or. long-term measurement primitive. 
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The flow direction for a RR is from a lower layer to a higher one. 
□ Layer State Information (LSI)-. Persistent state primitive. The flow direction 

for a LSI is from a higher layer to a lower layer, 
o Asynchronous Even. Notification (AEN): Asynchronous primitive to report 

recent, typicaUy non-persisten, events. The flow direction for an AEN is 

always from a lower layer to a higher one. 

^.genericfunctionati^fromasuperclasscalledOPLTmsWelassisno. 
par, ofmcmrplementedprotocols^aaaseparate entity; botitexclosiyely defines 
to minimum access interface (i.e. the primitives) for all me (derived) Pis, as shown 
„ Figure 9. The object-oriented sfiucmre of active interface objects in conjunction 
^ *e overal. mchitecmral framework allows implementation of an additional 
feature: (active) pro-mterfaces offer an afremativc medium to pass messages and 
feeilitate merein a common signalling and data API for application development. 

AS shown in Figme 10, active interfaces are to he used to provide access to ahribu.es 
wito mepro4ayersm«woways ; seouentiagy(seriesA)andoon-se q uentiaUy(series 

„, In series B, me attiihu.es from pro-layer NCL are supplied to the App.ication 
lay er via me PP. and API pro-interfaces, jumping the BSA pro-layer where those 
attributes are not needed. 
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The advantages of this architecture become apparent when OPtDvLA. is used in 
different communication networks; the signalling interface for applications then 
remains unchanged independent of the implemented protocol stack and the means of 
transport in the system. Adaptation to the target signalling system only takes place 
in the appropriate protocol (pro-layer) and that can flexibly be exchanged during run- 
time. 

III.2 OVERALL IMPLEMENTATION OF THE ARCHITECTURE 

L- and Pi-classes form the two major families/groups of classes that implement a 
protocol stack based on open programmable protocol interfaces. However, the 
functionality necessary to control signalling sequences, to deal with periodic tasks 
(e.g. channel measurements in the lowest layer) and to respond to external triggers has 
to be provided as well. 

To fulfil these tasks, the family of Thread classes (T-Classes) has been introduced; in 
this implementation, they use the multithreading features of Java to implement 
concurrent message processing. Java was chosen as the implementation platform 
because of features such as dynamic binding and platform independence. T-classes 
do not, however, define any other functionality, rather they access methods defined 
in L (and also PI)-classes and call appropriate functions in those classes. Priority of 
threads (and therefore execution priority of the message sequence) can be defined 
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during thread instantiation. 

Protocol Stack classes (PS-Class) represent the whole of a protocol stack; attributes 
of this class are instances of aU other (previously explained) classes. Thns, a PS-class 
oxptoits the functionality and to information of L-classes, uses me primitives defined 
inPI-classes and controls the execution of the tesks ofmeinstantiatedT-objecti, This 
denotes that instances of me PS-class deliver the desired protocol stack functionality 
hy implementing all required objects. Appropriate PS-class constructors can be used 
,o implement any standard protocol stack (provided the layer classes for these 
standards are available). Using this stincture, a protocol stack can be dynamically 
adapted to anyparticular set of requirements by exchanging the appropriate (pro-layer 
and thread) classes. 

The following class 
Figure 11): 

L nT -_ ^ „ ft. PVr.ti.ss d dhunsna: L-objects can access prhnidves of a Pl- 
dass to commnnicate widr higher or lower layers, whilst me Pi-class provides access 
,o ore information stored in a L-objec, or trigger any method implemented within mis 
(L-) object. 

r m||n -.-^.^^T^^T-obie^^nsemeappmpriate^ributesmKl 
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methods of L- and Pi-objects to carry out its pre-defined task. 
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PS-class has L, PT and T-objects as attributes: PS-objects can use the functionality and 
the information defined in these objects directly. 

T-clas.sss-.depend on the PS class: PS-objects control starts and stops of various 
threads in its main method, but T-objects are solely responsible for the task execution. 
This is illustrated in Figure 1 1. 

All classes are structured in a class library, which provide the required signalling 
functionality to any network entity. The reason why classes are grouped in packages 
is to provide a base level of security. Declaring only the PS-class public ensures that 
the other objects become (theoretically) invisible and inaccessible to any other non- 
related object. The 'public' object is allowed to access the 'private' or 'protected' 
methods within the scope of its own attributes. 

Although T-objects are directly used in the main method of a PS-object, L, PI and T- 
objects are used as attributes within the PS-class, and these attributes are the instances 
which define the appropriate objects as members of one protocol stack e.g. the 
reference of the PS-object is mostly used as a parameter in the methods of an L-class. 
In this way, if a method of an L-object is called, the object can identify the Pi-objects 
belonging to the same PS-object and use their attributes and methods (i.e. messages). 
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This is show, in Figure 9- Two opera*™! modes tor Protocol Stack objects trigger 
signalfag/message sequences. These are either: internal (i.e. the PS-object initiates 

orternrhratestlueadexecution without external triggers but caused by a Hme-ont) or 
(U. events occurring at the application or physical layer). Both of these 

operational modes lead evenraally to the instantiation or tennination of the appropriate 



The flexibility of this architechrral approach is based on tire introduction of the 
generic Pis and is father consolidated by the possibility of using several concurrent 
a^ads. Generic Pis deliver tire means necessary to access L-objects and to support 
T-objects, they provide the flexible structure necessary to support and implement 
different protocol stack standards. The generic set of primitives between the 
actional entities ofthePS remains unalteredCevenif newpro-layerimplemen^tions 
axe introduced, as long as the messages comply to the four primitive types); this 
denotes mat the Pl-elasses can access any pro-layer class, without being subject to 



IV IMPLEMENTATION MODEL 

There now follows a description of a specific implementation of the OP.IMA model. 
To assess proper functionality of programming interfaces, a set of QoS related 
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messages, methods and classes has been defined and organised in a class library. The 
motivation for choosing QoS signalling as a test case has been the increasing 
complexity of interactions and variety of QoS demands expected in future generations 
of mobile networks, when users will be able to request mixed services (i.e. voice/ 
video/data and other Internet services). Aurrecoechea et al ("A survey of QoS 
Architectures", ACM/Springer Verlag Multimedia Systems Journal, Special Issue on 
QoSX Architecture, Vol 6, No. 3, ppl38-151, May 1998) compare a number of 
different QoS architectures and discuss their particular features. It is stated that most 
QoS architectures merely consider single architectural levels rather than the end-to- 
end QoS support for multimedia communications. Furthermore, it is pointed out that 
QoS management features should be employed within every layer of the protocol 
stack and QoS control and management mechanisms should be in place on every 
architectural layer.— 



Here, a model has been implemented that incorporates support for end-to-end and 
level controlled QoS negotiation as examples to show both functionality and to test 
proper operation of communication signalling within the OPtEVIA architectural 
framework. There now follows the definition of a generic QoS signalling message 
specification, a description of the protocol stack and the QoS negotiation 
implementation. Model 1 implementation is based on a RMI platform (running on 
Sun Solaris workstations) where a number of applets are implemented and used as 
representations of signalling (application) end points. 
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A S e« of messages and parameters are specified and defined for a generic QcS 
signalling structure buil, on the OPtTMA protocol framework. Messages and their 

of^ds^oncaBafo^ageneralrde.mmesaage^^m^ 
name specification is defined as: 

^eofPro^glnterfaceirrypeof ^W^^r^^^U) 

The following message is given as. an.example, 

APISRMSerReq(String typeOf Service) { } 

^suressageispartoftheAPHtaterfacebeC.eenSignaUingAppUcadonLayerand 
Application Layer. K is derived ftorn ute pritnitive OT e ■Service Rerp.es. Messag, 
(SRM) and contains a string as argument (i.e. typeOf Service). AU messages (,.e. 

SR M and LSI are downwards (from upper .ayer to ,ower iayer), RR and AEN arc 
active in me upwards direction (i.e. lower to higher layers). 

indicated in the numbering system used: 



. \ i* i _v Message from Layer 2 to 
PPI23RRTypeOfVariable(arguments) { } ~* Mess ° 

Layer 3 
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PPI32LSITypeOfVariab]e(arguments) { } -»• Message from Layer 3 to 

Layer 2 

APIPPILSITypeOfVariable(argument) { } Message from Application 

Layer to Layer 4 

PPIAPIAENTypeOfVariable(arguments) { } -»• Message from Layer 4 to 

Application Layer 

Some of the messages may use the active feature of the OPtEvIA and may have to 
access other than subsequent layers (e.g. application sending a message directly to the 
link layer), this as well is defined in the command naming: 
API2SRMTypeOfSRM(arguments) { }. 

The remainder of this part contains as an example the complete list of SRMs, LSIs, 
RRs and AENs defined for the QoS signalling API. Model 1 has enabled verification 
and validation of both the architecture and the specification of programming 
interfaces. To prove the validity of OPtlMA and proper functioning of the pro- 
interface implementations, the QoS messaging part of the API has been taken as an 
example. 



Service Request Message (SRM) 



SRM 


Parameters 


Description 


APISRMSerReq 


p.index 


Service Request 


APISRMSerChange 


p. index 


Service Modification Request 


APISRMDisconnect 


P 


Disconnection 


APISRMSerContd 


P 


Service Continues 
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Layer State Information (LSI) 




Asynchronous Event Notification (AEN) 



APIAENSerReqOK 



APIAENSerRegFail 



APIAENQoSProvided 



APIAENSerChangeOK 



APIAENSerChangeFail 



Description 



Serv ice Request OK 
Service Request Fail 



Provided QoS for Service 

Request : 

Service Modification Request 
OK 



Service Modification Request 
Fail 



Request Reply (RR) not applicable 

Figures 12a and 12b, depict the skeleton 
.nessagesfortheAPIpro-interfacerespectively. Therenow* 
freimplementedmodel and class structure for QoS negotiation and management at 

the API. 



code for QoS negotiation and the set of 
v follows descriptions of 



IV.l MODEL DESCRIPTION 



ta Mode! 1 A.**— — — ^ * server appl e« -d a 
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in OPtlMA facilitate messaging between client and server using Java RMI as transport 
media. 

The applets are used as signalling end-points to negotiate and display the QoS 
settings. Communication between those end-points takes place via the API using an 
underlying layer class (pro-layer), which implements the RMI connection via 
interfaces (Stub and Skeleton) to the Java Object Broker (RMI). Client-Stub and 
Server-Skeleton implementations in this model, are representative of the pro-layer 
classes. The protocol stack (used in this test platform) consists of an application layer 
(L-class), an API (Pi-class) and a general layer class (L-class) representing the 
remainder of the protocol stack. The functionality of this model relies on the basic 
client/server principle, where objects are distributed across the network and 
communicate via a middleware layer (object broker). Clients request services, via the 
request broker, from remote server objects. The (RMI) broker uses interfaces bound 
to the implementations of clients and servers called stubs and skeletons, respectively. 
Stubs and skeletons hide the complexity of the cornmunication between client and 
server, they control sterilisation and de-marshalling of parameters and they establish, 
maintain and terminate connections between the remote entities. Application layer 
classes are implemented as applets (Client Applet and Server Applet), they provide 
the graphical user interface (GUT) of the signalling end-points. Java AWT (abstract 
windowing toolkit) is used to implement the GUI and Solaris on Sun workstations as 
computing platforms. 
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Tne genera! layer class (RMI das, dien, and Class Server) represents .he .est- 
pla tfom,version of u,e protocol stack. This Cass is derived from to signalling 

™ .his class. Moreover, to general layer class accesses to Java's RMI Snub and 

Skeleton class. MO- - *™ - taPleme " ted M 

and toy provide to means for (RMI) distributed ebjee, computing endpoints, as 
shown in Figure 13. Client and Server applets are shown in Figures .4 and 15, 
respectively. Their data fields represent requested and provided QoS parameters. 

The Apple. 'Client' consists ofanumber of components tot include: 

. A text area, which is used to inform to user about general events. 
. Nta e text fields, which display the parameters of an established 
connection. 

. A multiple choice, which enables the user to request a specific service. 

A text field, where the user inserts the destination Id. 
. A number of buttons, which are used to enable the user to interact with 

the terminal. > 



B Applet 'Server' consists of the following set of components: 

. A text area, which is used to inform the administrator about general 
events. 

. A column of nine text fields, which display either the parameters of an 
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established connection or the parameters of a request (depending on the 
type of the last request). 

A column of multiple choices, which manually detennine the current 
conditions of the network. The manual determination of the network 
conditions was necessary, since there is not an actual flow of user data. 
The test platform implements the signalling plane of the protocol stack. 
Thus measurements of the flow parameters such as delay and BER are 
not feasible. 

A choice, which is used to enable the administrator to deny all the 
requests independently of the current network conditions. 



The parameters, which are used to describe the quality of service and the quality 
provided by a connection (or a service request), are as follows: 

Standard: Determines the type of standard e.g. GSM, DECT, etc. 

IdField: Determines the identity of the client (e.g. TMSI/IMSI for 

GSM). 

Locationld: Specifies the location of the mobile client (e.g. LAI for 
GSM). 

Bandwidth: Determines the bandwidth of a connection or a request in 
kbps. This bandwidth can specify average, maximum, best effort, 
predicted or guaranteed bandwidth, depending on the type of standard. 
Delay: Specifies the delay of a connection or a request. It could be 



PCT/GB01/02169 



29 

best effort, predicted or guaranteed 



referred to average, maximum, 
delay, depending on the type of standard. 
. Priority: Specifies the relative importance of a connection with respect 
to the order in which connections are to have their QoS degrated (if 
necessary) and the order in which connections are to be released to 
recover resources (if necessary). 
. Protection: Determines the extent to which a Service Provider attempts 
to prevent unauthorised monitoring or manipulation of user-originated 
information. 

The experimental se,-up consisted of the server applet running on a SUN Solaris 

connect ,0 tire server machine via an ATM tab (over 10/100 Mbits/s Ethernet 
connections). As an examp.e of operahon of Model . indentation, we briefly 
ascribe the operation of.be simplified signalling messages setruenee for QoS re- 
negoriahonpresen.eamFigure.6. The cbentre^amooirlcationofthe already 

^^^^^^^^^^■^ 
required QoS parameters and information related to the identity of the client. The 
serverprocease.ttiismt.uestandexantinesmere^dQoS.meavai.abitityofloeal 

«si.e.curren.loadmg due to all clients, and the resources already assignedto 
(Service Modification Knsponse). The client acknowledges the previous message 
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(Service Modification Response ack.). In case the request is not accepted, the client 
can either disconnect or continue the current session with the previous QoS values. 

The described embodiments have the following significant attributes: 

A protocol re-configuration platform (i.e. an architectural framework 
containing a detailed specification of a library of generic interface 
classes (APIs/PPIs) is provided and used to implement reconfigurable 
protocol stacks in a flexible and open manner using object oriented 
prograrnming techniques. 

Implementation guidelines/specifications to build standard and non- 
standard protocol stacks using the APIs and PPIs (provided in the 
defined libraries). Using an open programming platform requires the 
specification of how applications and protocol layers are to be 
programmed. 

The API/PPIs can work with legacy implementation of protocol layers 
as well as component-based forms of protocol layer i.e. the framework 
supports composible protocols. 

Protocol reconfiguration requires the control/supervision of a 
"Reconfiguration Manager" unit. 

Two different implementation models for the proposed open 
programmable protocol interfaces have been proposed and assessed. 
Both offer the required flexibility to support protocol stack re- 
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configuration. The first possible solution proposes an architecture in 
which even the interfaces are implemented as objects, whereas the 
second proposal follows the classical definition of APIs, in which the 
API is merely a formal definition implemented in the underlaying layer. 
Although both implementation strategies can be supported within 
OPtlMA, the current OPtlMA architecture has been based on the 
former of the two implementation models. 

By extending the existing base protocol classes and customisation, it is 
possible to implement application-specific behaviour i.e. users are 
permitted to install and run their own custom protocol stacks, protocol 
layer or addition/deletion of components within any given layer, thus 

It is assumed that Protocol classes are implemented compliant to the 
appropriate API/PPI, by the vendors. 

The proposed Pis are capable of mapping the application QoS onto 
network and link-layer QoS parameters, as required within wireless 
mobile networks. * y 

The OPtlMA architecture is implemented in Java. Java platform was 
selected as it supports code mobility, OO properties, serialisation, 
inheritance and encapsulation properties. 
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CLAIMS 



1. A protocol stack for a communications system wherein the stack has an 
architecture incorporating active programming interfaces capable of supporting 
reconfiguration of the stack. 

2. A protocol stack as claimed in claim 1 comprising 

a plurality of protocol layers and a plurality of said active programming 
interfaces interleaved with said protocol layers, wherein functionality of said protocol 
layers is defined by protocol layer classes and functionality of said active 
prograniming interfaces is defined by programming interface classes. 

3. A protocol stack as claimed in claim 2 wherein execution of the respective 
functions of said protocol layer classes and said programming interface classes is 
controlled by thread objects defined by thread classes. 

4. A protocol stack as claimed in claim 3 wherein said classes are stored in one 
or more class library. 

5 . A protocol stack as claimed in claim 2 wherein said protocol layer classes have 
functionalities derived from a generic layer class and said programming interface 
classes have functionalities derived from a generic interface class. 
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, Apro.ocolsUck^clatoedtoc.aimJwherein^dpro.ooollayerd^.said 
by a protocol stack class. 

7 A protocol stack as claimed in data 6 whereto said protocol stack class 
during protocol reconfiguration. 

8 . Ap.o.ocolslackasclaimedinclairnTwhcreinsaidprotocolstackclassdoflncs 
the structure of the stack. 



, Aorotocolstockasclataedtoanyoneofclaims ! to 8 whereto said protocol 
layK s consist of a physical layer, a link control layer, a network control layer, a 
signalling application layer and an application layer. 

,0 A protocol stack as claimed in any one of claims 2 to 9 whereto said active 
programming interfaces axe configured to enah.e direct signalling communication 

of said protocol layers . 

„. A protocol stock as claimed to claim 5 wherein said generic interface class 
defines a plurality of basic control messages (primitives). 
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12. A protocol stack as claimed in claim 1 1 wherein there are four said primitives 
consisting of Service Request Messages, Request Responses, Layer State Information 
and Asynchronous Event Notification, 

13. A protocol stack as claimed in any one of claims 2 to 4 wherein at least one of 
said classes depends on at least one other class. 

14. A protocol stack as claimed in claim 4 wherein said one or more class library 
is a secure library. — 

15. A protocol stack as claimed in any one of claims 6 to 8 wherein said protocol 
stack class is publicly available. 

16. A protocol stack as claimed in claim 1 wherein said active prograrriming 
interfaces enable access to attributes within protocol layers of the stack either 
sequentially or non-sequentially. 

17. A reconfigurable protocol stack for a communications system comprising, 

a plurality of protocol layers' and a plurality of active programming interfaces 
interleaved with said protocol layers, wherein each said protocol layer has 
functionality defined by a layer object selectable from a respective one of a plurality 
of different layer classes, each said active programming interface has functionality 



defta ed by an interface objee, selec»b>e from a respective c„e of a plurality of 
d» for condoning message sequences within the protocol stack. 



18 A protocol stack as claimed in claim 17 wherein each said 
^mncdona^rromagenedcmterfaceclaasmatiseonnnontoaUsaidinterftce 



19 . A protocol stack as claimed in clahn 18 wherein each said interface class 
defines additional functionality specific to the respective interface class, 

20 . A protocol stack as claimed in claim 18 or claim 19 wherein said generic 
interface class defines a plurality of basic control message types. 

21 A protoco! stack as claimed in claim 20 wherein said baste control message 
and Asynchronous Event Notification. 

22 Apto.ooolstackasc,aimedmanyoneofclaimsn,o2.ineludingapro.ocol 
suck class armuged to implement said ,ayer classes, said interface ciasses and said 
thread classes. 
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23. A protocol stack as claimed in claim 22 wherein said protocol stack class is 
further arranged to exchange, dining run-time, one said layer object for another said 
layer object from the same layer class and/or exchange one said interface object for 
another said interface object from the same interface class whereby to change 
functionality of a corresponding said protocol layer and/or a corresponding said active 
programming interface during protocol stack reconfiguration. 

24. A protocol stack as claimed in any one of claims 17 to 23 wherein said layer 
classes, said interface classes and said thread classes are stored in, and selectable from 
a class library. 

25. A protocol stack as claimed in claim 22 or claim 23 wherein said layer classes, 
said interface classes and said thread classes are stored in, and selectable from a class 
library, and implementation of said protocol stack class provides a public interface. 

26. A protocol stack as claimed in any one of claims 1 7 to 25 wherein said active 
programming interfaces are so configured as to permit messages to pass directly 
between any two said active programming interfaces by-passing any intervening 
protocol layer. 

27. A protocol stack as claimed in any one of claims 1 to 26 wherein each said 
layer class inherits functionality from a generic layer class common to all said layer 
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and has additional functionality specific to the respective layer class. 



28. A protocol stack as claimed in any one of claims 18 to 21 wherein a said layer 
class inherits functionality from said generic interface class. 

29. A protocol stack as claimed in any one of claims 17 to 28 wherein said thread 
classes derive functionality from said layer and interface classes. 

30. A communications system comprising a network and at least one terminal 
respectively incorporating a protocol stack as claimed in any one of claims 1 to 29, 
each said protocol stack being independently reconfigurable. 

31. A communications system as claimed in claim 30 wherein said at least one 
terminal is a software-reconfigurable radio. 

32. A method for reconfiguring a protocol stack for a communications system, the 
protocol stack comprising a plurality of protocol layers and a plurality of active 
programming interfaces interleaved with the protocol layers, each said protocol layer 
having functionality defined by a layer object selectable from a respective one of a 
plurality of different layer classes and each said active programming interface having 
functionality defined by an interface object selectable from a respective one of a 
plurality of different interface classes, the method including the step of exchanging 



WO 01/88707 PCT/GB01/02169 
38 

one said layer object for another said layer object from the same layer class and/or 
exchanging one said interface object for another said interface object from the same 
interface class whereby to change functionality of the corresponding protocol layer 
and/or the corresponding active programming interface. 

33. A protocol, stack substantially as hereindescribed with reference to the 
accompanying drawings. 



34. A communications system substantially as hereindescribed with reference to 
the accompanying drawings. 
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public class ProtocoiStack {II class which, 
implements the PS functionality 
Layert 11: " fundamental 

Layer2 12: 
Layer3 13: 
PU2 pi12: 
Pi23pi23: 
QoS qos: 



II elements 
II of 
II the 
II Protocol 
II Stack 

//Constructor 



ProtocoiQ { 
11 = new layert () 
!2 = newLayer2() 
13 = new Later3(). 
P i12 = newPi12() 
P i23 = newPi23() 

I 



public void mainQ { 

qos = newQoS(this): 
creation of Thread 

Thread qos Thread = new Thread(qos): 
responsible for QoS 

qos Thread.startQ: 
starting the thread 

} 



class Layerl { 



class Layer2 ( 
} 

class Layer3 ( 
•} 

class PH2( 
■■} 

class Pi23( . 

....] 

class QoS implements Runnable { // 
class responsible forQoS Management 

ProtocoiStack p: 

QoSlProtocolStack protocol) { 
I/Constructor 

this.p = protocol 

} 

public void run() ( II whenever this 
thread is called 



Pro-interface and -layer class frames 
& QoS - thread 



PS - skeleton 



Fig.12 
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